SYMPTOM: self.TICKS_PER_METER is always at default value, regardless
of value in roboclaw.launch or any other parameter server.

CAUSE: A typo in call to rospy.get_param() means it is trying to
retrieve a value that does not exist, instead of the intended
parameter value.

FIX: Add missing 's' to properly retrieve 'ticks_per_meter' value

SYMPTOM: Unpredictable erros occurring at runtime
    File "roboclaw_node.py", line 232, in run
        rospy.logdebug(" Encoders %d %d" % (enc1, enc2))
    TypeError: %d format: a number is required, not NoneType

CAUSE: Error when calling roboclaw.ReadEnc would result in encoder
values 'enc1' or 'enc2' to be None instead of a number. This triggers
TypeError as described above.

FIX: Do exactly what TypeError wants us to do: make sure both 'enc1' and
'enc2' are numbers before trying to format them as numbers for logging.
(Note this does not address root cause of ReadEnc failure, that will be
submitted as a separate fix.)

REFERENCE: Python number check courtesy of StackOverflow: https://stackoverflow.com/questions/3441358/what-is-the-most-pythonic-way-to-check-if-an-object-is-a-number

SYMPTOM: Unpredictable errors when calling roboclaw API, manifesting
in several different forms such as "OSError: 11"

CAUSE: The roboclaw API is not thread-safe, but we have three different
threads potentially calling into the API simultaneously. When this
occurs, errors follow.
1. self.run for our '/odom' publisher thread
2. self.cmd_vel_callback as  '/cmd_vel' subscriber
3. self.check_vitals running for diagnostics

FIX: Use a threading.Lock() object to synchronize usage of roboclaw
API object. Thereby ensuring only one thread will be communicating
with roboclaw at any given time.

REFERENCES:

ROS Python API Threading Model
https://answers.ros.org/question/9543/rospy-threading-model/

StackOverflow "Semaphores on Python"
https://stackoverflow.com/questions/31508574/semaphores-on-python

SYMPTOM: When robot turns right, /odom pose orientation turns left.
(And vice versa.) However, the odom->base_link transform is correct.

CAUSE: Encoder odometry entry point update_publish(enc_left,enc_right)
is invoked with update_publish(enc1, enc2). But this is backwards. As
per cmd_vel_callback, motor 1 is the right-hand side motor and motor 2
the left-hand side. As a result odometry calculations are reversed.

Why does the odom->base_link transform look OK? An earlier change
added a negative sign in front of the published transform angle. This
only masked the error without fixing the underlying cause, resulting in
reversed /odom data and leaving variables like self.last_enc_right
holding the wrong values.

FIX: Reverse the parameters when calling update_publish so they are
correct. And now that the underlying problem is addressed, the negative
sign must be removed from the angle when publishing transform.

Fix typo when reading ticks_per_meter parameter

merge changes

- according to docu rev. 5.4
- for firmware 4.1.34